为什么不使用 scrapy，而是从头编写爬虫系统？

写过十几只爬虫，大的抓过几十亿个数据项那种。我也符合题主所说的不用scrapy，而是从标准库写。核心问题是框架封装的厚度问题。

每一种框架，目的是把常用操作的多个步骤封装成通用的接口，隐藏一些复杂性。但框架设计的好坏就存在一个封装厚度是否合适的问题。所谓封装的厚度，是对外接口如果能跟底层操作有较为明显的对应，就是薄封装，而把底层屏蔽的啥都看不到了，则属于厚封装。好的厚封装也要有足够的部署量，成为一种标准才行。

历史上能做成功的厚封装其实很少很少。举一个网络编程的例子。以BSD Socket为界。现代操作系统提供的基础网络接口可以认为都是从BSD Socket发展起来的。而BSD Socket就是对底层网络复杂性的厚封装。使用BSD Socket的人并不需要知道每个调用的底层是如何处理组包，重传，窗口等细节。于是经过几十年的发展，BSD Socket成了网络编程的标准底层，任何一个想在网络编程上有所成就的人，都不可避免的了解BSD Socket的每个函数和参数细节。

而在BSD Socket之上也有一些网络编程封装。比如很多面向对象语言做了对象化封装。使得发生每个事件时，就会由框架自动调用某个对象的方法。但各种语言的各种框架里，对这种回调方式的框架并没有一个统一的标准，比如连接成功，收到数据等回调函数，并没有个统一的名字。使得熟悉了一个面向对象回调网络框架的人，难以将知识复用到另一个框架上。

而在BSD Socket之上的薄框架也有。比如Python的socket模块，就只是把基础的Socket调用的第一个参数变为对象的引用而已。其余的参数和类型之类的都是一一对应的。少数做了点易用性封装，如没发完字节的重试之类的。

回到问题，scrapy就是典型的厚封装框架。将任务管理，访问重试等等内容封装了起来。但用户却难以知晓其内的逻辑，或需要看很多文档才能掌握其内部细节逻辑。而掌握这部分逻辑，所付出的努力，对以后的其他工作并没有什么用处。这导致了很多用户不愿意去用。

同理，如果各位软件工程师要去设计框架时，也应该保有该思路。如果自己不是某个领域的大牛，就应该避免设计厚封装框架，否则提高了用户的学习成本就会导致用户不愿意去学习和使用。而应该尽量使用薄封装框架，使得用户可以最大化的复用以前的知识，让框架的使用更加直观。